惨痛教训！Dropbox 放弃用 C++ 开发移动应用

（给程序员的那些事加星标）

Dropbox 是全球知名的网盘服务商。

2013 年，Dropbox 的移动开发团队还很小，同时还有一个经验丰富的 C++ 老司机核心团队。

那年，Dropbox 开发移动应用所采用的策略是：开发一套 C++ 代码，在 Android 和 iOS 之间共享。当年移动开发团队小，他们又要支持快速增长的移动路线图，所以就采用这个策略。

8 月 15 日，Dropbox 工程师 Eyal Guthmann 在官方博客发文，宣布彻底放弃上面这种策略，将采用移动应用的原生开发方式。他们将选用 Kotlin 和 Swift 来开发 Android 和 iOS 应用。

问：为什么会做出这种转变？

答：代码共享带来的隐形成本/额外开销

Dropbox 通过非标准方式开发移动应用，产生了额外开销。如果是采用用移动应用原生开发方式，则不用担心额外开销。这种开销，最终比开发两套原生代码昂贵的多。

Eyal 表示，其实 Dropbox 从来没有达到用 C++ 开发大部分代码库的程度。采用C++ 的开销，实际上阻止了他们完全朝着这个方向前进。

另外，值得注意的是，像谷歌和 Facebook 这样的大公司多年来一直在开发可扩展的代码共享解决方案。到目前为止，这些解决方案只获得了有限的采用。

这些额外开销，体现在 4 个方面：

a. 定制框架和库的开销

用 C++ 开发，最容易预测的开销，也就是框架和库了。Dropbox 博文中举例列出了 3 个框架。

上图中红色标注的 3 个库/框架，Dropbox 都已经在 GitHub 开源了。虽然如此，Eyal 表示，如果采用原生开发方式，这些库/框架都不用开发了。

此外，这种开源库，其实对移动开发的贡献，不如他们对原生开源库的贡献大。

b. 定制开发环境的开销

移动生态系统有许多工具可用来提高开发效率。移动开发的 IDE 非常丰富，谷歌和苹果投入了大量资源，使其成为开发人员在相应平台上的最佳开发体验。

而 Dropbox 摆脱这些平台的默认设置，放弃了其中一些好处。值得注意的是，使用移动平台原生语言做调试的体验，通常优于通过用 C++ 代码进行调试。

c. 处理平台差异之间的开销

尽管 iOS 和 Android 应用程序都是“移动应用程序”，通常都具有相同的特性和功能，但平台本身存在一些影响实现的差异。例如，应用程序在每个平台上执行后台任务的方式是不同的。

当 Dropbox 采用跨平台开发策略时，即使是开始时非常相似的事情，随着时间的推移也会有很大的差异（例如，与摄像机滚动的交互）。

因此，真正编写代码一次就在不同的平台上运行，其实是做不到。必须花费大量时间将代码集成到不同的平台。

d. 培训、招聘和留住程序员的开销

Dropbox 在开发移动应用时，他们是有一个牛叉的 C++ 程序员老司机团队。C++ C++ 老司机们还在内部培训了其他移动开发者对代码做贡献。

随着时间的推移，有些 C++ 老司机转到其他项目/团队，或者是离职跳槽了。留下来的工程师，没有足够的经验来填补技术领导的空缺。并且越来越难招到同时具备（丰富 C++ 经验 && 对移动开发感兴趣的）高级工程师。

因此，最终 Dropbox 缺乏维护关键 C++ 代码库的人才。 

想解决这个问题，Dropbox 尝试两种方式：① 对外直接招吧，但他们的岗位消息，挂了一年，没有招到。② 那就内部培训吧。结果自家的移动开发者对 C++ 不感兴趣。

除了招人问题，后来还遇到留住人才的问题。自家的移动开发者根本不想做 C++ 项目，很多优秀的移动开发者痛苦地离开了这个项目。

后话

在 Dropbox 博文的最终总结中，是这样写的：

「尽管编写一套可以共享的代码听起来很划算，但采用这种方法的成本超过了好处，事实结果还证明，这种好处比预期的要小。最后，我们决定不再通过 C++（或任何其他非标准方式）共享移动代码，而是用移动平台的原生语言来编写代码。

此外，我们希望我们的工程师有一个愉快的经验，能够为社会作出贡献。这就是为什么我们决定使我们的实践与行业标准保持一致。」

希望 Dropbox 的踩坑经验，对大家有帮助。

往期热文（点击图片即可阅读）

关注「程序员的那些事」加星标，不错过圈内事

好文章，我在看❤️